TESSY接口编辑器主要用于整理测试对象的输入、输出、返回值、全局变量和外部函数调用。模块分析完成后，TESSY会尝试自动判断接口元素的传递方向，但自动分析的结果不一定能完全符合测试的意图。在正式设计测试数据之前，应当先对接口定义进行检查，否则一旦参数方向、数组范围或指针目标的识别出现错误，后续的测试用例也会跟着错位。

在TESSY当中，测试对象的创建与识别不完整的排查，关键是要让TESSY拿到完整的待测源码和编译环境，再通过模块分析把可测试的函数识别出来。测试对象出现缺失的时候，问题往往不是出在测试用例上，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，跟正式的工程没有对上。排查的时候，应当先去看一看分析日志，然后再去检查预处理之后的源码内容。

在单元测试的收尾阶段，TESSY测试文档到底该怎么去生成，它的格式又要怎么去调整，这是很多项目在准备交付评审时都会撞上的事情。实际工作中，不少团队在TESSY里已经把测试用例设计好了、桩函数也配过了、覆盖率也统计了、连执行结果都确认完了，可等到真要拿去给别人看的时候，才发现手头的测试文档要么内容不完整，要么格式乱糟糟的不统一，再要么就是测试报告跟项目的其他证据对不上号。TESSY的测试文档，并不是简单导出一份报告就能算完事的，它还得能把测试的对象、测试的环境、测试的用例、执行的结果、代码的覆盖率，还有缺陷的处理情况都给说明白，这样后面才能稳稳地撑住ASPICE、ISO 26262这些评审，或者企业内部的质量审查。

如果只是盯着这一轮测试是通过还是失败，那TESSY历史结果的对比和回归差异的定位能看到的东西其实很少。回归测试真正要去解决的问题，是在代码、测试数据、桩函数、编译环境甚至目标平台发生过变动以后，确认原来已经跑通的那些功能有没有被意外碰坏。所以动手做历史结果对比之前，一定得先把用来比较的基准给找稳了，再一茬一茬地把差异拆开来细看，不能一瞧见Fail就急急忙忙判断代码里头出了毛病。

在嵌入式软件单元测试这一块，把测试从主机搬到真实的硬件上去跑，TESSY目标板上怎么执行、执行后的日志又该怎么去看，是绕不开的实际问题。TESSY是支持在不同目标系统上跑C和C++的嵌入式软件测试的，从测试设计、执行，到结果分析和报告管理这一整套流程它都能覆盖，在目标板上跑的时候，工具会把测试的输入传到目标系统那边，去运行被测的函数，然后再把实际的输出取回来，跟预期结果做一次比对。

做单元测试的时候，TESSY里的MC/DC覆盖率该怎样去统计，那些没被覆盖到的空洞又要怎么补上，这是围绕着结构覆盖来展开的。TESSY这个工具是支持代码覆盖率分析的，覆盖率一般说的就是那些已经被测试执行到的代码项在全部代码项里占的比例，而MC/DC比起普通的语句覆盖和分支覆盖来，要求还要更细一些，它不光要求条件被跑到过，还得去证明每一个条件都能单独地去影响整个判定的结果。所以我们在TESSY里面去看MC/DC的时候，不能光去盯那个百分比是不是到了100%，还得去瞧一瞧有哪些判定没有被覆盖到，又有哪些条件没有表现出它的独立影响。

在嵌入式软件测试中，很多人都会碰到TESSY集成测试怎么去搭建，以及依赖模块替换又要怎样去处理这两个挺现实的问题。做单元测试的时候，大部分精力是放在单个函数上，看它自己的逻辑走得对不对，但一转到集成测试，事情就变了，你必须把好几个模块合到一起，去检查它们互相之间的接口调用是不是符合约定、数据是怎么传的、状态切换正不正常，还有当异常发生时，整个组合体还能不能稳稳地撑住。TESSY这个工具在管理测试用例、输入输出、覆盖率和报告方面确实能帮上忙，可真到了要动手设计集成测试那一步，我们首先得把测试的边界画清楚，把依赖关系理出来，再定好替换的策略，不能想着光靠工具自己去跑就能交差。

在嵌入式软件单元测试中，TESSY桩函数的返回值怎么模拟、调用顺序又该怎么校验，是实际项目里常常碰到的两个问题。很多被测函数并不是完全独立运行的，它在执行时总会去调用一些外部的函数，比如底层驱动、通信接口、诊断接口或者存储接口等等，如果让这些外部函数直接参与测试，结果就很容易被硬件环境、通信状态甚至其他模块干扰，所以需要先用桩函数把外部依赖替换掉。桩函数的重点，并不是随便写上一个空函数就算完事，而是要能模拟返回值、输出参数、调用次数还有调用的先后次序，这样得出来的测试结果才有真正的价值。

在动手用TESSY的分类树编辑器还有生成测试数据组合的时候，很多人会把注意力放在怎么使用和怎么生成上面，其实真正要留心的地方，不是简单地把输入值摊成几个测试用例就算完事。更靠得住的思路，是先把被测函数的输入条件、会得出什么输出结果，还有那些处在边界上的情况拆解清楚，然后再用分类树这套方法组合出一批相对完整、又不会重复太多的测试数据。分类树编辑器，也就是常说的Classification Tree Editor或者CTE，它本身就是用一种图形的办法来设计测试用例规格的工具，常见的做法是先找出测试相关的方面和对应的类别，然后再把不同的类别拼成测试用例。

TESSY里头的需求追溯怎么去建，覆盖矩阵又要怎么去看，很多人在做嵌入式软件单元测试的时候，都会撞上这类事情。需求追溯这件事，倒不是把需求的编号往测试说明里头一抄就能完事的，它得要串起需求本身、测试对象、测试用例、运行出来的结果，还有报告里的证据这么一整条链子才行。TESSY本身是可以支持需求管理、支持你把需求导进来、让测试用例去引用需求，还能帮你做覆盖分析，再把报告给导出来，这些功能拿过来，正好能帮我们把单元测试的证据理得更清爽一些。